Proximity based ad-hoc messaging, alerting, and tracking system

ABSTRACT

A proximity based ad-hoc messaging, alerting, and tracking system can be employed to quickly and efficiently propagate alerts when a child or other individual becomes lost. Various types of alerts can be provided to facilitate locating a lost individual even in scenarios where a network connection or GPS is not available. The system can also be employed to track the presence of an individual after traveling in a vehicle to enable detecting when the individual has been separated from all guardians such as would be the case when the individual is left in the vehicle.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/269,474, which was filed on Sep. 19, 2016 and which claims thebenefit of U.S. Provisional Application No. 62/222,293, which was filedon Sep. 23, 2015.

BACKGROUND

The need to locate lost individuals, pets, or items has long been aproblem. Additionally, people often leave their pet or child in the carresulting in disastrous consequences that could have been easilyavoided. In the case of missing children, research has shown that themost critical aspect of successfully locating a child is the speed atwhich he or she can be found. Presently, systems such as the Amber Alertsystem require a relatively large amount of time upfront. For example,the parent must realize the child is lost, contact law enforcement, andexplain the incident, after which law enforcement must confirm theabduction and then proceed to send alerts to the population. Due to theamount of time that elapses before the alerts are sent, Amber alertsoften cover a large geographical area to account for the distance thatthe perpetrator may have traveled in the interim.

Some tracking systems have been created to address the inherent delaysin the Amber alert system. With these tracking systems, the child orother individual must carry a tracking device that is capable ofcommunicating over a network (e.g., a Wi-Fi or cellular network) toreport its location. Oftentimes, location is reported using GPScoordinates. which may not always be available (e.g., when the child isindoors) rendering such systems unreliable. Also, if the child isseparated from the tracking device or the tracking device loses power,the system will fail.

BRIEF SUMMARY

The present invention extends to a proximity based ad-hoc messaging,alerting, and tracking system. This system can be employed to quicklyand efficiently propagate alerts when a child or other individualbecomes lost using a short range wireless protocol. Various types ofalerts can be provided to facilitate locating a lost individual even inscenarios where a network connection or GPS is not available. The systemcan also be employed to track the presence of an individual aftertraveling in a vehicle to enable detecting when the individual has beenseparated from all guardians such as would be the case when theindividual is left in the vehicle.

In one embodiment, the present invention is performed by a user deviceas a method for implementing an alerting system. The user device canmonitor for alerts that are transmitted using a short range wirelessprotocol. The user device can then receive a first alert that includesan alert identifier that indicates that an individual is lost and anidentifier of the lost individual. In response, the use device cangenerate and send a second alert that includes an alert identifier thatindicates that an individual is lost and the identifier of the lostindividual. The user device can also use the identifier of the lostindividual to obtain and display information about the lost individual.

In another embodiment, the present invention is implemented as computerstorage media storing computer-executable instructions which whenexecuted on a user device implement a method comprising: monitoring foralerts that are transmitted using a short range wireless protocol;receiving a child lost alert that includes an identifier of a lostchild; and generating and periodically sending a child lost forwardedalert that includes the identifier of the lost child.

In another embodiment, the present invention is implemented as a methodfor tracking an individual. A user device can determine that the userdevice is traveling in a vehicle, and can monitor for presence alertsfrom other devices within proximity of the user device. Each presencealert can include an identifier of either a guardian or an individualfor which the guardian is responsible. In response to receiving presencealerts, the user device can compile a list that includes the identifierscontained in the presence alerts. The list can include an identifier ofa child device and an identifier of another user device. The user devicecan detect that the user device is no longer traveling in the vehicleand, in response, send the compiled list to a server. The user devicecan then continue to monitor for presence alerts from the child device.Upon ceasing to receive presence alerts from the child device, the userdevice can notify the server that the user device is no longer receivingpresence alerts from the child device.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Understanding that these drawings depict only typical embodiments of theinvention and are not therefore to be considered limiting of its scope,the invention will be described and explained with additionalspecificity and detail through the use of the accompanying drawings inwhich:

FIG. 1 illustrates an example computing environment in which the presentinvention can be implemented;

FIG. 2 illustrates various known packet formats;

FIG. 3 illustrates how the present invention can employ a common beaconpacket format to transmit alerts;

FIG. 3A illustrates various example alert packets that can be employedin embodiments of the present invention;

FIGS. 4A and 4B provide an example of how alerts can be broadcast andpropagated in a peer-to-peer fashion;

FIG. 5 provides another example of how alerts can be broadcast;

FIG. 6 illustrates how a device can employ an identifier contained in areceived alert to obtain context of the alert;

FIGS. 7A-7C illustrate various examples of user interfaces that can bedisplayed to a user to notify the user of an alert and to allow the userto respond to the alert;

FIG. 8 provides a flowchart of the process that a device can performwhen a packet containing an alert is received;

FIG. 9 illustrates how the present invention can be employed in vehiclesituations;

FIGS. 9A-9E illustrate the process by which one or more guardians can benotified when a child is detected as no longer being in the presence ofat least one of the guardians.

DETAILED DESCRIPTION

The present invention is generally directed to a messaging, alerting,and tracking system. As an overview, this system can be employed topropagate alerts when someone or something is lost. This specificationwill primarily describe embodiments in which the system is employed whena child is lost. However, the same techniques can equally be employedwhen any individual or any item has become lost or otherwise separatedfrom a parent or other guardian. In the claims, the term individualshould be construed to encompass any type of individual including achild, an elderly person, or a mentally impaired person.

FIG. 1 illustrates a computing environment 100 in which the proximitybased ad-hoc messaging, alerting, and tracking system of the presentinvention can be implemented. Computing environment 100 is shown asincluding a number of user devices 101 a-101 n, child devices 102 a-102n, and location devices 103 a-103 n (where n represents any integer andwill typically be very large) In typical embodiments, user devices 101a-101 n are computing devices (which are preferably mobile devices suchas smart phones) capable of both receiving and transmitting packetsusing a suitable short range wireless protocol (e.g., any device capableof transmitting and receiving Bluetooth Low Energy (BLE) packets). Childdevices 102 a-102 n can be any device capable of transmitting packetswhether or not it is also capable of receiving packets. For example, achild device may be a smart phone or a beacon configured to send out BLEpackets containing advertising channel PDUs. Location devices 103 a-103n are typically simple devices configured only to transmit packets(e.g., beacons), but could be any device capable of transmittingpackets.

In this specification, a beacon should be construed as a simple devicethat is configured to only transmit advertisement packets. In typicalembodiments, a beacon can be configured to transmit such advertisementpackets as iBeacon packets encapsulated as the PDU of a BLE packet. Abenefit of employing beacons for child devices 102 a-102 n and locationdevices 103 a-103 n is that they require very little power and cantherefore operate for a long period of time without replacing thebatteries.

Each of user devices 101 a-101 n can include an application (e.g., amobile app) or an operating system feature that is configured to beinvoked when an advertisement is received. For example, a mobileapplication could be registered with a Bluetooth component of thedevice's operating system to receive BLE packets such that the operatingsystem passes received BLE packets to the mobile application forprocessing. The application/feature can also be configured to broadcastpackets in various situations as will be described below. In contrast,child devices and location devices can be configured to continuouslybroadcast packets as will also be further described below.

FIG. 2 illustrates a current format of a BLE packet that can be used totransmit advertisements. As this format is known by those of skill inthe art, it will not be described in detail. Of importance toembodiments of the present invention is how the iBeacon packet formatcan be employed within the data portion of a BLE advertising channelPDU. As shown, the data portion of the advertising channel PDU formatcan be 31 bytes. An iBeacon packet divides these 31 bytes into a 9 byteheader, a 16 byte proximity UUID, a 2 byte major field, a 2 byte minorfield, and a 2 byte TX power field.

Turning now to FIG. 3, an example of how this iBeacon packet format canbe employed to identify a particular type of alert as well as toidentify an individual, pet, item, etc. that is the subject of thealert. In this specification, the term alert will be used generally todescribe any type of advertisement packet that is broadcast by any typeof device (e.g., by a user device, a child device, or a locationdevice). As shown, the present invention defines an alert packet formatin which the proximity UUID field of an iBeacon packet is used to definean alert identifier while the combination of the major and minor fieldsof the iBeacon packet is used to define an identifier of the subject ofthe alert.

FIG. 3A provides examples of various types of alerts that can beemployed including a child lost alert type 301, a child lost forwardedalert type 302, a child presence alert type 303, and a location alerttype 304. As mentioned above, each type of alert can be identified usinga specific alert identifier. In embodiments that employ the iBeaconpacket format, this alert identifier can be a 16 byte number. Forexample, the child lost alert identifier can be defined as“a50bb6e-0025-4d18-bab8-0308db25662d” such that any child lost alertwould include this 16 byte identifier within the proximity UUID field.Similarly, the child lost forwarded alert identifier can be defined as“f0908652-4bb2-48a2-95c8-3e03bba9da99” such that any child lostforwarded alert would include this 16 byte identifier within theproximity UUID field.

The terms “child lost,” “child lost forwarded,” and “child presence” areused only to describe a typical context in which these alerts are used.However, these alerts can also be used in the context of otherindividuals or items. For example, when an elderly individual is lost, achild lost alert containing an identifier of the lost elderly individualcan be broadcast. Similarly, an elderly individual or item maycarry/include a child device that broadcasts a child presence alert. Inshort, the present invention can be implemented in the same mannerregardless of the individual or item that has become lost.

A unique 4 byte identifier of the subject of the alert can be storedacross the major and minor fields thus enabling billions of differentsubjects (e.g., children, elderly, pets, locations, etc.) to existwithin the system. With some alerts, this identifier will represent anindividual or item to be monitored or tracked (hereinafter a “childidentifier”), while with other alerts, this identifier will represent alocation (hereinafter a “location identifier”). As will be described indetail below, the inclusion of this identifier can allow a receivingdevice to query a server for context of the alert as well as to makevarious determinations regarding how to respond to a received alert.Although iBeacon and BLE may be employed in preferred embodiments (dueto their currently ubiquitous nature), the present invention may equallybe employed with other suitable short range communication protocols andpacket formats.

As mentioned above, child devices 102 a-102 n and location devices 103a-103 n can typically be in the form of beacons which continuouslyadvertise their presence. In other words, each of these devices canperiodically broadcast a BLE packet containing the appropriate alert. Inthe case of a child device, a child presence alert (e.g., an iBeaconpacket containing the child presence alert identifier as the proximityUUID) that includes the child's unique identifier (e.g., within themajor and minor fields of the iBeacon packet) will be broadcast. Incontrast, in the case of a location device, a location alert (e.g., aniBeacon packet containing the location alert identifier as the proximityUUID) that includes the location's unique identifier will be broadcast.Because the child and location devices continuously broadcast thesealerts, any user device that comes within proximity of the child orlocation devices will receive the broadcast alert and will become awareof the presence of the child or the location.

On the other hand, user devices 101 a-101 n can be configured tobroadcast child lost and child lost forwarded alerts. A user device canbroadcast a child lost alert when that user device is the initiator ofthe child lost alert. For example, if a parent determines that his orher child has become lost, the parent can employ his or her user device(e.g., by interacting with a mobile application) to broadcast a childlost alert that includes the identifier of the lost child. To facilitatethis process, the parent (or guardian) can have an account thatassociates the parent with one or more children. By virtue of beinglogged in to the account, the mobile application may provide the optionfor the parent to report that one of the associated children is lost(e.g., by selecting a representation of the lost child and providinginput identifying that the child is lost).

Regardless of how the parent indicates that a child is lost, the userdevice can commence broadcasting a child lost alert that includes thelost child's identifier. As a result, any other user device withinproximity will receive the child lost alert. In response to receiving achild lost alert, the receiving device can commence broadcasting a childlost forwarded alert that includes the same child identifier that wasincluded in the child lost alert. Any other device that receives a childlost forwarded alert can then rebroadcast the child lost forwardedalert. In this way, the alert can be propagated in a peer-to-peerfashion regardless of whether any of the devices have a networkconnection. In other words, the present invention can be employed topropagate an alert without requiring that the devices be connected tothe internet via Wi-Fi or a cellular connection.

One reason for employing the child lost forwarded alert rather thansimply rebroadcasting the child lost alert is to enable receivingdevices to determine whether they are within proximity of the initiator.In other words, if the receiving device receives the child lost alert,it can know that the initiator of the child lost alert is nearby. Insuch cases, if the user of the receiving device happens to locate thelost child, he or she will know that the parent/guardian is in theimmediate vicinity and can take appropriate action.

FIGS. 4A and 4B provide an example of how an alert can be propagatedwhen a child is lost. In this example, it will be assumed that a childis carrying a child device 102 a and that this child has been separatedfrom his parent who is carrying a user device 101 a. It will also beassumed that, upon determining that the child is lost, the parentprovides input to user device 101 a to initiate the process ofbroadcasting a child lost alert for the lost child. Therefore, in step1, device 101 a creates a child lost alert 401 by including the childlost alert identifier (a50bb6e . . . ) in the proximity UUID field of aniBeacon packet and an identifier of the lost child (which is assumed tobe 7d-d4) in the major and minor fields of the packet. Device 101 a thencommences broadcasting alert 401 (e.g., as part of a BLE advertisingchannel PDU) at a suitable interval.

It is assumed that user device 101 b is within proximity of user device101 a (and that user device 101 b is configured to participate in thesystem such as by including the appropriate mobile application or OSfeature). Therefore, user device 101 b will receive alert 401. Userdevice 101 b can examine alert 401 to determine that it is a child lostalert based on the presence of the child lost alert identifier in theproximity UUID field. In response, user device 101 b can create andbroadcast child lost forwarded alert 402 as represented by step 2. Asshown, child lost forwarded alert 402 includes the same child identifier(7d-d4) but includes the child lost forwarded alert identifier (f0908652. . . ) rather than the child lost alert identifier. Any other userdevice that receives alert 401 would perform this same process tocommence broadcasting alert 402.

Turning to FIG. 4B, it is assumed that while user device 101 b isbroadcasting alert 402, user device 101 c comes within proximity of userdevice 101 b and receives alert 402. In response, and as indicated instep 3, user device 101 c will determine that alert 402 is a child lostforwarded alert and will commence broadcasting it (not shown). Also, instep 4, which may or may not occur prior to step 3 as will be describedbelow, user device 101 a receives child presence alert 403 which isbeing broadcast by child device 102 a. User device 101 c can detect,based on the inclusion of the child presence alert identifier (de0e8586. . . ), that alert 403 is a child presence alert. User device 101 c canalso identify the child identifier 7d-d4 and use it, in step 5, todetermine whether a child lost alert has been issued for the identifiedchild. As indicated above, user device 101 c may receive alerts 402 and403 in any order. Therefore, user device 101 c can store an indicationof which alerts it has received for a suitable duration of time. In thecase that alert 402 is received prior to alert 403, user device 101 cwill compare the child identifier within alert 403 to the stored childidentifier it received in alert 402. In contrast, if alert 403 isreceived prior to alert 402, user device 101 a will compare the childidentifier within alert 402 to the stored child identifier it receivedin alert 403. In this way, user device 101 c will be able to determinethat it is within proximity of the lost child.

When a child lost alert (or child lost forwarded alert) is received, thereceiving device may store the corresponding child identifierindefinitely (e.g., until it is notified that the alert has beencancelled which may occur in any suitable manner including by using achild lost cancellation alert). This may be the case even if the deviceceases to receive the child lost (or child lost forwarded) alert fromother devices. In contrast, in some embodiments, when a child presencealert is received, the receiving device may store the correspondingchild identifier for a suitable amount of time after the device ceasesto receive the child presence alert. One reason for this is to ensurethat, if a device leaves the proximity of the lost child, it may stilldetect that it may be in somewhat close proximity to the lost child if acorresponding lost child alert is received.

Upon determining that it has received matching child lost and childpresence alerts, user device 101 c can take appropriate action. Theexact type of action can vary based on a number of factors as will bedescribed below. As an example, the user of user device 101 c could beimmediately notified that he or she is within proximity of a reportedlost child and can be given an option to communicate directly with theparent. Alternatively, user device 101 c may automatically communicatewith user device 101 a. In either case, the type of response may dependon whether user device 101 c is currently able to obtain additionalinformation about the lost child (e.g., by using the child's identifierto query a server over the internet for a phone number or other contactinformation of the parent or to query the server for information thatthe user device can employ to directly communicate with user device 101a).

FIG. 5 illustrates an alternate scenario in which user device 101 c iswithin proximity of location device 103 a when it receives childpresence alert 403. Because user device 101 c is within proximity oflocation device 103 a, it will receive location alert 404 that includesa location identifier (3a-bf) representing the physical location oflocation device 103 a. As an example, location device 103 a may bepermanently positioned at a convenience store, a park, a school, etc.Upon receiving location alert 404 and in conjunction with receivingalerts 402 and 403, user device 101 c will be able to additionallyreport a location of the lost child. For example, the locationidentifier included in location alert 404 could be submitted to a serverto retrieve specific details about the location of location device 103a. These details could be displayed to the user of user device 101 cand/or could be reported back to user device 101 a as part of reportingthe presence of the lost child. Of course, if a location device is notin proximity when a lost child is detected and the user device thatdetects the presence of the lost child is receiving a GPS signal, thecurrent GPS coordinates could be employed to report the location.However, since GPS may not always be available (e.g., when indoors), theuse of location devices can enhance the reliability of the system.

FIG. 6 provides an example of how a user device can employ a child orlocation identifier contained in a received alert to obtain associatedcontext/information from a server when a network connection isavailable. As shown, user device 101 c receives an alert that includeseither a child identifier or a location identifier. This alert can beany of the types of alerts previously described as well as any othertype of alert that may be suitable for use within the described system.Upon receiving the alert, user device 101 c can extract the child orlocation identifier (e.g., from the major and minor fields of an iBeaconpacket) and submit a context request 601 that includes this identifierto a server 600. Server 600 can maintain a mapping between identifiersand their corresponding context and can therefore employ the identifierin context request 601 to retrieve the corresponding context. Server 600can then send a context response 602 that includes this context back touser device 101 a.

This context can be any type of information about the location or childthat may be usable to facilitate locating a child for which a child lostalert has been initiated. For example, for each child identifier, server600 may maintain context consisting of the child's name, contactinformation of the child's parent or guardian, a picture of the child,etc. In some cases, this context could be updated after a child isdetermined to be lost to include the color or type of clothing the childis currently wearing, a last known location of the child, anidentification of an individual with whom the child was last seen, etc.Similarly, for each location identifier, server 600 may maintain contextconsisting of a name of the location, an address of the location,directions to the location, etc.

When a user device receives a context response, the user device candisplay the context to the user to assist the user in locating a lostchild (or other individual, pet, or item). To address privacy concerns,a user device may be configured to request and/or display context for achild identifier only in response to a child lost alert or child lostforwarded alert. In other words, a user device may be configured to notrequest and/or display context in response to receiving a child presencealert unless or until a corresponding child lost alert has beenreceived. This would prevent a user from viewing context of a nearbychild when the child is not lost. Similarly, a user device may beconfigured to only retrieve context for a location identifier when doingso could help the user report the location of a lost child. In this way,the number of network communications can be kept at a minimum. In short,although a user device could request context in response to receivingany type of alert, it may be configured to only do so when a child lostalert has been received and the user device determines that it is withinproximity of the lost child.

FIGS. 7A through 7C each depict an example of how context of anidentifier can be displayed to the user. In FIG. 7A, it is assumed thatuser device 101 c has received either a child lost alert or a child lostforwarded alert. In response, user device 101 c can display anappropriate notification. Additionally, user device 101 c can extractthe child identifier from the alert and use it to obtain the associatedcontext as described above (whether automatically upon receiving thealert or in response to user input selecting the notification). In thisexample, it will be assumed that the context includes the child's name,Jimmy Wilson, and a picture. This context can then be displayed on userdevice 101 c such as in response to the user selecting the notification.As shown, the context can be displayed in conjunction with a text areain which the user can input a message that can be sent to the initiatorof the alert (e.g., user device 101 a in the example in FIGS. 4A and4B). The display can include a send button which when selected willcause the input message to be transmitted. The display may also includea call button which when selected will initiate a call to the userdevice that initiated the alert. As mentioned above, in someembodiments, the retrieved context may include the necessary informationto allow user device 101 c to communicate with the initiating userdevice. For example, the context may include a phone number of theinitiating user device or another type of identifier for sending anelectronic communication to the initiating device.

FIG. 7A generally represents a case where user device 101 c receives thechild lost or child lost forwarded alert when a corresponding childpresence alert has not been received. In such scenarios, the context canbe displayed to the user even though the user device has not received acorresponding child presence alert. This is so because the child may notbe carrying a child device and therefore the user device may neverreceive a corresponding child presence alert even when the lost child isnearby. In particular, the context can be displayed so that the user canattempt to visually identify the lost child.

In contrast, in FIG. 7B, it is assumed that user device 101 c alsoreceives a child presence alert having the same child identifier as thechild lost or child lost forwarded alert. As mentioned above, the alertscould be received in any order. In this scenario, user device 101 c maydisplay the same type of context as previously described, but may alsoinclude an indication that the child is located nearby therebyencouraging the user to look for and identify the child in the vicinity.In cases where the child presence alert is received after the child lostalert, the display of the context could be automatically updated (andadditional notifications could be output) to reflect that the lost childhas come within proximity of the user.

FIG. 7C represents the scenario when the user device also receives alocation alert. In this scenario, the user device can employ thelocation identifier of the location alert to retrieve the locationcontext. The location context could then be included in the display. Forexample, as shown, the displayed context can include an indication thatthe lost child is located at Macy's shoe department. In such cases, thislocation context could be communicated back to the initiating deviceeither automatically or as part of a manually initiated message.

Although not shown, in scenarios where the user device receives a childpresence alert and a matching child lost alert (as opposed to a childlost forwarded alert), the user device may display the context inconjunction with an indication that the user is within proximity of boththe child and the parent (i.e., the initiator of the child lost alert).This may be the case when the parent and child are not within proximityof one another, while the user is physically located between the childand parent and within proximity of both. This may inform the user thathe or she can locate and deliver the child directly to the parent.

The retrieval and display of context can be performed by any user devicethat receives alerts. In this way, the fact that a child has become lostcan be propagated quickly to those that are likely to be within thevicinity of the lost child. In particular, because most people carry asmart phone that can function as a user device, alerts can be quicklyspread in a peer-to-peer fashion in the area where the child may mostlikely be (e.g., in an area surrounding a parent that was last incontact with the child). As these alerts spread from user device to userdevice, the context of the alert can be displayed to the users toquickly inform them of the situation thereby greatly increasing thelikelihood that the child will be found.

FIG. 8 provides a flowchart of an example process 800 that a user devicecan perform upon receiving a packet containing an alert. As describedabove, in some embodiments, the packet may be a BLE packet whichencapsulates an iBeacon packet containing an alert identifier in theproximity UUID field and a child or location identifier spanning themajor and minor fields. The received packet could have been transmittedfrom another user device (when the packet is a child lost alert or achild lost forwarded alert), from a child device (when the packet is achild presence alert), or from a location device (when the packet is alocation alert).

As a first step, the user device can examine the contents of the packetto identify which alert identifier it includes. For example, inBLE/iBeacon embodiments, the user device can extract the contents of theproximity UUID field of the iBeacon packet. Once the user device hasobtained the alert identifier, it can then determine whether it is alocation alert (e.g., by comparing the alert identifier from the packetto the known location alert identifier). When the alert identifier is alocation alert identifier and a network is available, the user devicecan use the location identifier from the received packet to query theserver for the location context. If a network is not available, thelocation identifier can be stored with a timestamp. Although notrepresented in the flowchart, if a network becomes available and theamount of time that the location identifier has been stored does notexceed some threshold, the user device can then use the locationidentifier to retrieve the location context. In some embodiments, theuser device can be configured to delete stored location identifiersafter a specified amount of time.

Whenever location context is retrieved, the location context can bestored on the user device in association with the location identifier.In this way, the stored location context will be available for displayand/or transmission at an appropriate time (e.g., upon receiving a childpresence identifier). The location context can also be stored inassociation with a timestamp which may identify when the user devicelast received a location alert containing the corresponding locationidentifier. In this way, the user device will be able to identifywhether stored location context should still be considered relevant.

If the packet is not a location alert, the user device can thendetermine whether the packet is a child presence alert. If so, it can bedetermined whether a matching child lost alert or child lost forwardedalert has been received by comparing the child identifier in the childpresence alert to child identifier(s) that were previously stored (aswill be described below). When a child lost or child forwarded alertmatching the child identifier of the child presence alert has beenreceived, the user device can take appropriate action to notify the userthat he or she is within proximity of the lost child. As describedabove, this can include retrieving and displaying context (or onlydisplaying context if it has been previously retrieved from the server).When no matching child lost or child lost forwarded alert has beenreceived, the child identifier in the child presence alert can bestored. In this case, the child identifier can be stored in associationwith the child presence alert identifier (or some other child presenceindicator) so that the user device can know that the child identifierwas stored in response to receiving a child presence alert as opposed toa child lost alert. At this time, if a network I available, the userdevice may also retrieve the context for the child identifier and storeit for later use.

Finally, if the packet is not a location alert or a child presencealert, the user device can determine whether the packet is a child lostalert or child lost forwarded alert. Although not addressed in thisflowchart, there may be other types of alerts such as a child lostcancellation alert that when received can cause the device to stopbroadcasting child lost forwarded alerts and delete the correspondingchild identifier that would have been stored.

Assuming the packet is a child lost or child lost forwarded alert, theuser device can rebroadcast the alert (if it is not already doing so).The user device can also determine whether a matching child presencealert has been received. This can be accomplished by determining whetherthe child identifier in the child lost or child lost forwarded alertmatches a child identifier that is stored in association with a childpresence identifier. When there is a match, appropriate action can betaken including by displaying the appropriate context to the user asdescribed above. In contrast, if there is not a match, information aboutthe child may still be displayed to the user but without the indicationthat the child is nearby. Also, the child identifier from the alert canbe stored in association with the child lost alert or child lostforwarded alert identifier to thereby enable the matching step to beperformed when a child presence alert is subsequently received.

In addition to the techniques described above, the present invention mayalso be employed to implement a tracking technique for use when a child(or other individual, pet, or item) is travelling in a vehicle with oneor more parents/guardians. For example, FIG. 9 illustrates a scenariowhere two parents that are carrying user devices 901 a, 901 b aretravelling in a car with a child (or other individual, pet, or item)that is carrying child device 902. The car also includes a locationdevice 903.

In these tracking embodiments, the formatting and transmitting of alertscan be similar to what is described above except that user devices 901 aand 901 b can also be configured to transmit presence alerts which wouldinclude an identifier (e.g., a parent identifier) that uniquelyidentifies the parent. Accordingly, each of devices 901 a, 901 b, 902,and 903 can be configured to transmit presence alerts.

User devices 901 a and 901 b can include accelerometers capable ofdetecting movement. When user devices 901 a and 901 b detect movement inconjunction with the receipt of location alerts from a location deviceknown to be in a vehicle (which could either be pre-programmed into theuser device or determined from context retrieved using the locationidentifier of the location device), they can each trigger a process ofcollecting a list of any user/child devices within proximity. Therefore,in the example shown in FIG. 9, user device 901 a will compile a listidentifying user device 901 b and child device 902. Similarly, userdevice 901 b will compile a list identifying user device 901 a and childdevice 902. As described above, this can be accomplished by includingthe identifier contained in any received presence alert.

Both user devices 901 a and 901 b can continue to monitor whether theyare still travelling in the vehicle (e.g., by monitoring accelerometerdata to detect that motion indicative of traveling in a vehicle hasceased for at least a threshold amount of time). Once each user devicedetermines that it is no longer travelling in the vehicle, it cantransmit the compiled list to a server. The server can store each ofthese lists. In this way, the server can know that, upon leaving thevehicle, child device 902 was within proximity of user device 901 a andwithin proximity of user device 901 b (i.e., that the child was withboth parents).

At this point, user devices 901 a and 901 b may cease broadcastingpresence alerts. However, both user devices 901 a and 901 b willcontinue to monitor for child presence alerts received from child device902 to determine whether the child device remains within proximity ofthe user device. If either of user devices 901 a or 901 b detects thatit is no longer within proximity of child device 902 (e.g., bydetermining that it has not received a child presence alert for aspecified amount of time), the user device can notify the serveraccordingly. In response to such a notification, the server can updateits list for that user device to indicate that the child is no longerwith the parent. Additionally, because the updated list includes theidentifier of the other parent, the server can use the identifier of theother parent to access that parent's list. If the other parent's liststill includes the child's identifier, it can be determined that thechild is still with the other parent.

If the parent happens to come back within proximity of the child, asimilar process can be performed to add the child's identifier back tothe parent's list. This type of updating can be performed any time thechild leaves or enters the proximity of the parent. If at any time theserver determines that neither parent's list includes the child'sidentifier, the server can send an alert to both user devices to informthe parents that the child is not with either parent. The server mayalso allow either of the user devices to inquire whether the child iswith the other parent (i.e., whether the other parent's list includesthe child's identifier).

Of course, if only a single parent were riding in the vehicle, therewould only be a single list stored on the server. Therefore, if thechild were to leave the presence of the parent, the server woulddetermine that the child is not in the presence of any parent that wasriding in the vehicle and can immediately notify the parent. This sameprocess could be employed when more than two parents are involved aswell as for each child that may be riding in the vehicle. In short, theserver functions to verify that a child's identifier remains included onat least one list at all times.

FIGS. 9A through 9E provide a more detailed example of this process.Although this example involves two parents and a child, the same processcould be performed when any number of parents and any number of childrenare riding in the vehicle together.

In FIG. 9A, each of devices 902, 901 b, 901 a, and 903 are shown astransmitting presence alerts 950, 951, 952, and 953 respectively. Inthis state, and as represented in step 1, each of devices 901 a and 901b can monitor accelerometer data (possibly in conjunction with receivingpresence alerts from location device 903) to determine whether they aremoving in a vehicle. In step 2, upon detecting that they are moving in avehicle, each of user devices 901 a and 901 b can commence monitoringfor presence alerts and, in step 3, can compile a list of theidentifiers contained in received presence alerts. In some embodiments,the user devices may exclude the location identifier of location device903 from this list.

Turning to FIG. 9B, in step 4, each of user devices 901 a and 901 b candetect that driving motion has ceased. In response, in step 5, each userdevice can send its compiled list to the server which can store thelists in step 6. Accordingly, as shown, the server can store a list foruser device 901 a that includes user device 901 b's identifier (i.e.,the parent identifier associated with the user of user device 901 b) and902's identifier (i.e., the child identifier associated with childdevice 902). The server can also store a similar list for user device901 b. Then, in step 7, each of user devices 901 a and 901 b cancontinue to monitor for child presence alert 950 from child device 902.

Next, in step 8 shown in FIG. 9C, it will be assumed that user device901 a leaves the proximity of child device 902 and therefore ceases toreceive child presence alert 950. In response, in step 9, user device901 a sends a notification to the server indicating that it is no longerin the presence of child device 902. The server can respond to thisnotification in step 10 by updating user device 901 a's list to removechild device 902's identifier. Additionally, in step 11, the server canuse user device 901 b's identifier contained in user device 901 a's listto locate user device 901 b's list and determine whether it stillincludes child device 902's identifier. In this case, because userdevice 901 b has not reported that child device 902 has left itspresence, child device 902's identifier will still be present in userdevice 901 b's list. The server will therefore not need to notify eitherparent. Although not shown, if user device 901 a again receives childpresence alert 950, it can send a corresponding notification to theserver causing the server to add child device 950's identifier back toits list.

Turning now to FIG. 9D, while user device 901 a is outside the proximityof child device 902, user device 901 b also moves outside the proximityof child device 902 such that it no longer receives child presence alert950 in step 12. In response, in step 13, user device 901 b will send anotification to the server indicating that it is no longer in proximityto child device 902. The server will then update user device 901 b'slist to remove child device 902's identifier in step 14. Because theserver has removed an identifier from a list, it will thencross-reference any related list which in this case can be performed byemploying the identifier of user device 901 a contained in user device901 b's list to identify and acesss user device 901 a's list. Uponaccessing user device 901 a's list, the server will determine that childdevice 902's identifier is also not included in user device 901 a's listand will therefore determine that the child is not present with eitherparent.

As shown in FIG. 9E in step 16, upon determining that neither userdevice 901 a's list or user device 901 b's list includes child device902's identifier, the server can send a notification to both userdevices 901 a and 901 b informing the parents that the child is not witheither parent. In this way, the parents will be immediately notifiedwhen the child leaves the proximity of both parents and can take quickaction to find the child. The tracking system can therefore be employedto ensure that a child (or other individual, pet, or item) is not leftunattended in a vehicle or after leaving a vehicle.

Embodiments of the present invention may comprise or utilize specialpurpose or general-purpose computers including computer hardware, suchas, for example, one or more processors and system memory. Embodimentswithin the scope of the present invention also include physical andother computer-readable media for carrying or storingcomputer-executable instructions and/or data structures. Suchcomputer-readable media can be any available media that can be accessedby a general purpose or special purpose computer system.

Computer-readable media is categorized into two disjoint categories:computer storage media and transmission media. Computer storage media(devices) include RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”)(e.g., based on RAM), Flash memory, phase-change memory (“PCM”), othertypes of memory, other optical disk storage, magnetic disk storage orother magnetic storage devices, or any other similarly storage mediumwhich can be used to store desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer. Transmissionmedia include signals and carrier waves.

Computer-executable instructions comprise, for example, instructions anddata which, when executed by a processor, cause a general purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediateformat instructions such as assembly language or P-Code, or even sourcecode.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, tablets, pagers, routers, switches, and the like.

The invention may also be practiced in distributed system environmentswhere local and remote computer systems, which are linked (either byhardwired data links, wireless data links, or by a combination ofhardwired and wireless data links) through a network, both performtasks. In a distributed system environment, program modules may belocated in both local and remote memory storage devices. An example of adistributed system environment is a cloud of networked servers or serverresources. Accordingly, the present invention can be hosted in a cloudenvironment.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description.

What is claimed:
 1. A method, performed by a user device, for trackingan individual, the method comprising: determining that the user deviceis traveling in a vehicle; monitoring for presence alerts from otherdevices within proximity of the user device, each presence alertincluding an identifier of either a guardian or an individual for whichthe guardian is responsible; in response to receiving presence alerts,compiling a list that includes the identifiers contained in the presencealerts, the list including an identifier of a child device and anidentifier of another user device; detecting that the user device is nolonger traveling in the vehicle and, in response, sending the compiledlist to a server; continuing to monitor for presence alerts from thechild device; and upon ceasing to receive presence alerts from the childdevice, notifying the server that the user device is no longer receivingpresence alerts from the child device.
 2. The method of claim 1, furthercomprising: receiving a notification from the server indicating that theother user device is also no longer receiving presence alerts from thechild device.
 3. The method of claim 1, further comprising: commencingto again receive presence alerts from the child device; and notifyingthe server that the user device is again receiving presence alerts fromthe child device.
 4. The method of claim 1, wherein determining that theuser device is traveling in a vehicle comprises: receiving locationalerts from a location device contained in the vehicle; and receivingaccelerometer data indicating that the user device is moving.
 5. Themethod of claim 1, wherein receiving location alerts from a locationdevice contained in the vehicle comprises determining that the locationalert includes a location identifier that indicates that the locationdevice is contained in the vehicle.
 6. The method of claim 1, whereindetecting that the user device is no longer traveling in the vehiclecomprises: ceasing to receive accelerometer data that indicates that theuser device is moving.
 7. The method of claim 1, wherein the presencealerts are received via a short range wireless protocol.
 8. The methodof claim 7, wherein the short range wireless protocol is Bluetooth LowEnergy such that the alerts are in the form of Bluetooth Low Energypackets.
 9. The method of claim 1, further comprising: broadcasting, bythe user device, presence alerts while the user device is traveling inthe vehicle.
 10. The method of claim 9, further comprising: in responseto detecting that the user device is no longer traveling in the vehicle,ceasing to broadcast the presence alerts.
 11. A method, implemented by aserver that is in communication with multiple user devices, for trackingan individual, the method comprising: receiving, from a first userdevice, a first list that includes an identifier of a second user deviceand an identifier of a child device such that the first list indicatesthat the first user device has been receiving presence alerts from thesecond user device and the child device; receiving, from the second userdevice, a second list that includes an identifier of the first userdevice and the identifier of the child device such that the second listindicates that the second user device has been receiving presence alertsfrom the first user device and the child device; receiving, from thefirst user device, a notification that the first user device has ceasedreceiving presence alerts from the child device; in response to thenotification, updating the first list to remove the identifier of thechild device from the first list; and accessing the second list todetermine whether the second list includes the identifier of the childdevice.
 12. The method of claim 11, further comprising: upon determiningthat the second list does not include the identifier of the childdevice, sending, to the first user device, an alert that indicates thatthe child device is not within proximity of the first user device or thesecond user device.
 13. The method of claim 12, further comprising:sending the alert to both the first and second user devices.
 14. Themethod of claim 11, further comprising: receiving, from the first userdevice, a second notification that the first user device has resumedreceiving presence alerts from the child device; and in response to thesecond notification, updating the first list to include the identifierof the child device.
 15. The method of claim 11, further comprising:receiving, from the second user device, a second notification that thesecond user device has ceased receiving presence alerts from the childdevice; in response to the second notification, updating the second listto remove the identifier of the child device from the second list;accessing the first list to determine whether the first list includesthe identifier of the child device; and upon determining that the firstlist does not include the identifier of the child device, sending, tothe second user device, an alert that indicates that the child device isnot within proximity of the first user device or the second user device.16. The method of claim 15, further comprising: sending the alert toboth the first and second user devices.
 17. A method for tracking anindividual, the method comprising: while travelling in a vehicle,compiling, by a first user device, a first list of identifiers, thefirst list including an identifier of a second user device obtained froma presence alert received from the second user device and an identifierof a child device obtained from a presence alert received from thechilde device; while travelling in the vehicle, compiling, by the seconduser device, a second list of identifiers, the second list including anidentifier of the first user device obtained from a presence alertreceived from the first user device and the identifier of the childdevice obtained from a presence alert received from the child device; inresponse to detecting that the first user device is no longer travellingin the vehicle, sending, by the first user device, the first list to aserver; in response to detecting that the second user device is nolonger travelling in the vehicle, sending, by the second user device,the second list to the server; receiving, by the server, a notificationfrom the first user device that the first user device has ceasedreceiving presence alerts from the child device; in response to thenotification, updating, by the server, the first list to remove theidentifier of the child device from the first list; and accessing, bythe server, the second list to determine whether the second listincludes the identifier of the child device.
 18. The method of claim 17,further comprising: upon determining that the second list does notinclude the identifier of the child device, sending, by the server andto the first and second user devices, an alert that indicates that thechild device is not within proximity of the first user device or thesecond user device.
 19. The method of claim 17, further comprising:determining that the second list includes the identifier of the childdevice; receiving, from the first user device, a second notificationthat the first user device has resumed receiving presence alerts fromthe child device; and in response to the second notification, updatingthe first list to include the identifier of the child device.
 20. Themethod of claim 17, further comprising: receiving, from the second userdevice, a second notification that the second user device has ceasedreceiving presence alerts from the child device; in response to thesecond notification, updating the second list to remove the identifierof the child device from the second list; accessing the first list todetermine whether the first list includes the identifier of the childdevice; and upon determining that the first list does not include theidentifier of the child device, sending, to the first and second userdevices, an alert that indicates that the child device is not withinproximity of the first user device or the second user device.